feat(api): accept user and team locators on grants - #1192

## TL;DR

Creating a grant by email address (`POST /grants` with
`user.identifier`) now answers `202 Accepted` with no body, whatever
happened: a match, a duplicate, an unknown address or an ambiguous one
all get the same empty reply. Nothing to compare across repeats, no id
to replay. Creating by `user_id` or team keeps `201` with the grant,
whose `user` / `team` now carry only the id. Reads (`GET`/list) still
return identifier and display. Granting yourself is rejected by user id
as well as by identifier.

## Why

Marco recorded the leak on issue #1229: PR #1192 made the HTTP status
neutral, but the body still hydrated the user on a hit and not on a
miss. The first commit here stripped the body to ids only. Copilot then
showed that ids alone still leak: a repeat returned the same grant id on
a hit and fresh random ids on a miss, and the returned user id could be
replayed through the explicit path, where 409 and 404 tell the two
apart. The second commit removes the body from the identifier path
entirely.

## What changed

- The identifier path returns a nil grant from the service and the
handler answers with the generated empty `202`. The synthetic-grant and
existing-grant helpers are deleted.
- Creating by `user_id` or team never hydrates refs: one id-only builder
produces every `201` body. The old `hydrateCreated` helper is gone.
- Self-grant check also runs on the explicit `user_id` path.
- OpenAPI: new `202` response on create, `201` scoped to the id and team
locators, locator and error descriptions rewritten. Regenerated ogen
files. Changeset for `@zitadel/server` (minor).
- The Console discards the create reply and the CLI prints an empty
result on 202, so neither needed code changes (typecheck and tests were
run for both).

<details>
<summary>Not in this PR: the users-query allowlist cleanup</summary>

The issue's third task, dropping `QueryUsers` from the session allowlist
in `internal/api/security.go`, is left out on purpose. That map does not
grant access. It marks operations that need a logged-in user rather than
any session cookie, so removing the users query from it would let an
anonymous cookie through, the opposite of the goal. The switch that
decides whether a browser session may call the users query at all is the
security block on `POST /users/query` in the OpenAPI, where the session
cookie is listed as an accepted credential.

Flipping that switch is not right either. The add-admin picker is not
the only caller: the Console users page lists users through the same
session call, and the CLI calls it too (with a project secret, so
unaffected). The users query already checks whether the caller may list
users of the session's project. What is missing is a permission that
only admins hold, and that is #1024's job. Until it lands, anyone with
any access to the Console project sees the list, a limitation the issue
already records.

Rate limiting the identifier path against volume and timing probes is
its own follow-up ticket, not part of this change.

</details>

## Tests

Written first, per TDD:

- Integration tests (postgres lane) covering bare create bodies on the
user_id, team, and identifier paths.
- A new key-set test that proves a hit response and a miss response have
identical JSON shape (same top-level keys, same nested user keys).
- A new test asserting your own `user_id` is rejected the same way your
own identifier already was.
- Service unit tests updated to match the id-only builder; the old
hydrate-fallback test deleted since there's no hydrate path left to fall
back from.
- Unit tests, `go vet`, OpenAPI lint, and check-generate all green.

Closes #1229